Что такое DWH? Почему бы нам не использовать привычные базы данных? Есть ли между ними отличия?
Представьте себе, что у вас огромное предприятие со множеством систем, каждая из которых решает отдельно взятую узкую задачу. Что же делать, если есть необходимость получать сводную кросспроцессную информацию?
В ходе доклада мы разберем особенности DWH, выясним, что же это за зверь.
Помимо общего знакомства с концепцией DWH, фокус доклада сосредоточен на том, что же конкретно делает аналитик на проекте DWH? Сложно это или просто? Какими компетенциями должен обладать такой аналитик и какие прикладные задачи он решает?
Целевая аудитория - системные аналитики, заинтересованные в работе с хранилищами данных, системные архитекторы. Уровень аналитиков любой, опыт работы с хранилищами данных не требуется.
Последнее время очень часто слышим про выгорание, кризис, желание перемен, «все бросить и уйти в закат», саббатикал...
Я прошла путь от осознания и принятия выгорания, потом «лечила» это долгим отпуском (5 месяцев). Нашла в себе силы и смыслы вернуться в аналитику и уже полгода работаю в команде мечты, контролирую свое состояние.
Поговорим о том, всем ли подходит этот вариант «лечения», как к нему подготовиться, чем можно заняться и как потом вернуться к работе.
В докладе рассмотрим работу системного аналитика в платформенной команде Райффайзенбанка, которая сопровождает несколько систем с разным стеком технологий.
Поделимся опытом оптимизации и повышения эффективности в команде за счет развития своих навыков по модели T-Shaped.
На примере задач расскажем какие навыки и инструменты полезны системному аналитику. Также рассмотрим возможное участие аналитика в смежных ролях. Приведем преимущества такого подхода для специалиста и команды в целом.
Содокладчик: Любовь Кислова
Про проектирование, моделирование ИС написано большое количество книг и статей, сделано значительное количество интересных докладов. Но несмотря на весь это без сомнения полезный труд, что многие из нас видят в проектах, продуктах или любом другом процессе или подходе, направленном на создание ИС, программные продуктов, сервисов и т.п.?
"Пилите таски из jira!". Вот и вся работа. А результаты проектирования пыляться и скучают где-то в килотоннах документации (если она есть), или находятся в голове 5% старожилов команды и строго хранятся этим орденом. Конечно, это скорее преувеличение, но тем не менее зачастую моделирование и проектироание или не включено в поток, или в ключено, но очень слабо.
В докладе будут затронуты возможные причины такого состояния, предложены варианты выхода из ситуации в конкретных сценариях.
Я расскажу про базовые принципы описания интеграционных интерфейсов, соблюдение которых является залогом быстрой и качественной интеграции. За 20 лет работы я выработала такие базовые принципы интеграций:
- степень детализации описания требований к интеграции зависит от срочности задачи и уровня зрелости команды разработки,
- соблюдать договоренности внутри команды / внутри проекта,
- учитывать справочные значения в интеграционных интерфейсах.
Кроме этого есть еще ряд нюансов, которые тоже следует учитывать в работе интеграционного аналитика:
- работу с пустыми и отсутствующими значениями,
- работу со всевозможными маппингами (преобразованиями) между разными интеграционными слоями,
- обработку ошибок на всех ветках алгоритма,
- сокращение Http Status Code = 500.
Если следовать этим принципам и учитывать нюансы, то "блох" интеграции, выявленных при тестировании и при выходе в ПРОД, будет в разы меньше.
В классических книгах по системному анализу, переведенных на русский язык, понятие потребность раскрывается недостаточно точно. В книге и на курсах системного мышления А. Левенчука (основанных на теории системной инженерии) это определяется как требование к надсистеме. Однако при изучении JTBD и техник user story и job story оказывается, что есть более удачные концепты. Кроме того сама техника job story часто ошибочно воспринимается, как конкурент user story, во многом из-за недостаточного материала и выступлений. В докладе мы пробежимся по базовым необходимым понятиям системной инженерии и дадим более удачное определение потребности, источника ее возникновения, разбиению на уровни системы и слоям (проблема-решение) и выразим user story, job story в этих смыслах. Нельзя сказать, что эта теория всеобъемлющая, так как опыт применения этого у автора в основном в ритейле при проектировании бизнес-процессов и их автоматизации, но, возможно, она будет полезна и в других сферах.
Перед выступлением будет полезно ознакомится с текстом https://habr.com/ru/post/529236/ или видео https://youtu.be/TbDnSQbMGjg о ценности, создаваемом ИТ аналитиком для бизнеса.
В мире разнообразия диаграмм сложно определиться, какую из них нарисовать для проектирования системы. А может нужно не одну? Влияет ли тип диаграммы на вырабатываемое решение?
На воркшопе составим диаграмму последовательности и опишем процесс в нотации bpmn и попробуем вместе спасти Красную Шапочку.
План воркшопа:
1. Погружение в контекст.
2. Делимся на команды, которые будут рисовать в разных нотациях. Командам даем ограничения и общую задачу — спасти Красную Шапочку. На одной диаграмме нужно будет изобразить разные ветки решений по спасению.
3. Делимся результатами работы между командами.
4. Делаем выводы.
Что ожидает бизнес, когда обращается к ИТ за автоматизацией? Что такое “полезная” автоматизация и когда бизнес будет действительно благодарен ИТ за автоматизацию процессов? А кто такой “Бизнес”, когда он выступает как заказчик информационной системы? Как c ним конструктивно взаимодействовать, чтобы Бизнес относился к ИТ как к уважаемым консультантам, а не как к еще одной затрате? Часто аналитики жалуются на то, что им недостаточно полномочий для влияния на бизнес-процессы заказчика и их никто не слушает, по сути заставляя создавать систему под устоявшиеся процессы. Почему так происходит? Все эти вопросы не так просты, и ответ на них получаешь только c длительным опытом, поработав c двух сторон: и как ИТ-специалист, выполняющий заказ, и как бизнес, обращающийся к ИТ за услугами. Поработав c двух сторон, мышление меняется. Если удовлетворить все собранные требования к системе, точно ли она будет полезна?
Своим докладом я хочу подтолкнуть к размышлениям на тему бизнес-ценности требований, дать советы как эту ценность анализировать, а также посмотреть по новому на взаимоотношения заинтересованных сторон в проекте, которые влияют и определяют бизнес-ценность требований к системе.
В основном мы будем говорить о заказной разработке.